[2021年版]Amazon GuardDutyによるAWSセキュリティ運用を考える

Amazon GuardDutyは脅威検知のサービスです。うまく活用してインシデントに対応するために運用方法をまとめます。

#Amazon GuardDuty

#セキュリティ

#AWS

臼田佳祐

2021.06.26

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

こんにちは、臼田です。

みなさん、AWSのセキュリティ運用してますか？(挨拶

Amazon GuardDutyはAWS上の脅威検知サービスです。今回はこのサービスにフォーカスしたセキュリティ運用を考えてみます。

ちなみにAWS Security Hubについても同じようにセキュリティ運用についてまとめたので以下もご確認ください。

AWSセキュリティ全体像

フォーカスしていく前に全体の整理をします。以下にざっくりとAWSにおけるセキュリティの要素について書き出してみます。

AWSレイヤー
- IAM管理
- ネットワークセキュリティ
- 設定管理
OS/アプリレイヤー
- 不正プログラム対策
- 脆弱性管理
- セキュアアプリケーション
- アプリケーション保護
全体管理
- ガバナンス・コンプライアンス
- サービス運用
- イベント・インシデント管理運用
- バックアップ・復旧

全体像といった割には少なくまとまりましたが、視点や書き方によっていくらでも増えたり減ったりするのでこれぐらいにしておきます。

様々なセキュリティの要素がある中でもGuardDutyは脅威検知であるので、不審なログ・挙動をベースにイベントを発行し、インシデント管理を行うためのサービスです。守るレイヤーはどちらかというとAWSレイヤーですが、OS/アプリレイヤーもスコープの範囲には含まれています。とは言ってもWebアプリケーションなどは対象外なのでSQLiとかXSSを検知できるわけではありません。そのあたりはWAFなどに任せましょう。

もう1つだけ視点を持ってきます。サイバーセキュリティフレームワーク(CSF)ではコア機能として識別、防御、検知、対応、復旧の5つがあります。GuardDutyは検知の役割を持っています。その後に続く対応と、対応のために必要な調査あたりも関連します。

How to improve threat detection and hunting in the AWS Cloud using the MITRE ATT&CK Matrixより引用

何かが起きてしまってからの対応に役に立つわけですが、当然その手前の識別や防御もきちんとやりましょう。

GuardDutyの概要

GuardDutyはAWS上で発生しているログを自動的に収集し、機械学習や脅威インテリジェンスを利用して怪しい動きを検知してくれます。

何よりも嬉しい点は簡単に利用できるところにあります。特に上記2つのポイントがそれぞれ簡単になっています。

従来の脅威検知は、検知するためにログを集約するところから始まりますが複数のばらばらの場所で出力されるばらばらのフォーマットのログを集約して分析できるようにします。ログの経路の確保やストレージの確保が必要です。GuardDutyではこれらを一切気にしなくていいです。ポチッと有効化すると、バックグラウンドで勝手に必要なログを収集してくれます。経路やストレージは気にすること無く、分析したログの量に応じた課金のみです。

次に課題になるポイントは脅威を検知する部分です。これもログの性質に合わせた経験に基づくしきい値や、利用状況に合わせたしきい値の調整、常に変わる攻撃者の情報などいっぱい大変です。これも全部自動でやってくれます。脅威を検知するための知識やインテリジェンスな仕組みは不要です。

イベント管理

GuardDutyで発生するイベントをトリガーにした運用管理を考えていきます。

イベント種類

まずはどのようなイベントが発生するかを把握します。

GuardDutyの検知結果はFindingsと呼ばれます。以下に一覧があります。

検索タイプ - Amazon GuardDuty

すべてのFindingsを正確に把握しておく必要はありません。運用中は主に実際に発生した際に確認します。ここではざっくりとしたところだけ押さえます。大きく以下の3つのタイプがあります。

EC2タイプはEC2がブルートフォースなど不審なアクセスを受けているというものや、既にやられてマルウェアがC&Cサーバーと通信していたりコインマイニングしたりするものを検知します。

IAMタイプはIAMが普段とは違う場所からログイン・利用されている、怪しいAPI実行を繰り返している、権限昇格をしているなどを検知します。

S3タイプはS3のデータを不正に取得しようとしたり、公開権限を変更したりするものを検知します。

通知

GuardDutyが脅威を検知したらイベントを通知しなければいけません。しかしGuardDutyには通知機能が直接ありません。EventBridgeにてFindingsが発生したことをトリガーに別のイベントに繋げることで通知が可能です。

参考までに以下ではEventBridge(旧CloudWatch Event Rule)からSNSを経由してメールで通知する仕組みを採用しています。

通知先はメールであることも一般的ですが、セキュリティインシデントの可能性があるため極力すぐに気付ける仕組みに通知すべきです。例えばSlackを定常的に利用していればこちらに通知するほうがいいでしょう。

GuardDutyにはイベント・インシデント管理機能(チケット管理機能)はありませんので、一旦JIRAやBacklogなどのシステムに連携して起票してからそれをSlackに通知なども有効です。

初動調査

通知を受け取ったら調査を開始します。最初にFindingsの概要と重要度などを指標に、実際にどのレベルで対応するか判断します。

例えばC&Cサーバーとの通信やコインマイニングなどはほぼ100%危険なセキュリティインシデントのため最優先で対応します。

普段利用していないポートが使われている、という場合は微妙なところです。ポート番号や通信先、利用者へのヒアリングも場合によっては行いながら判断していきます。

SSHブルートフォースを受けているだけであれば、きちんと防げている・他の影響がないのであれば特に問題はないと判断してもいいです。(この場合にはそもそもこれを受けない仕組みづくりが別で必要ですが)

このようなレベルの判断にはある程度知見が必要でもありますが、GuardDutyのUserGuideを利用することが判断の助けになります。これは実際にFindingsが発生した後にその画面から開くことが可能です。

以下図のように、Findingsを選択し、説明画面の「情報」を開き一番下の外部リンクを開くと確認できます。

例えばCryptoCurrency:EC2/BitcoinTool.Bの説明には以下のように書かれています。

EC2 インスタンスが暗号通貨関連のアクティビティに関連付けられている IP アドレスをクエリしています。

それぞれのFindingsに対応した確認する内容、誤検知の可能性の判断方法、対応方法などが解説されています。

初動のレベル感を判断できたら詳細な調査や影響範囲の確認・対応をしていきます。

以降はFindingsに応じてかなり変わるのでざっくりとやることだけピックアップします。

詳細な調査にはFindingsにかかれている対象のEC2インスタンス/IAM/S3の状態やそれらに関するVPCフローログ/CloudTrailログ/S3データアクセスログなどを確認しながら、誰がいつどのように操作したのかなどを確認していきます。この確認の為には事前にこれらのログを収集しておく必要があります。GuardDutyではログをユーザーに提供しているわけではないので、この詳細調査には事前の準備が必須です。ログの分析はAmazon Athenaを利用してクエリをかけると確認しやすいです。

これらの調査を簡単にするためのサービスとしてAmazon Detectiveもあります。以下も参照してください。

対応

一通り調査が出来たら対応していきます。あるいは緊急度の高いものは先にざっくり対応する場合もあるでしょう。対応もケースバイケースではありますがタイプごとにざっくり説明します。

EC2タイプ

EC2タイプはEC2インスタンスの内部で不正な仕組みが動いている場合に対応が必要です。コインマイニングなど初めから不正な操作のために立てられたインスタンスであればすぐに止めます。

しかし実利用していたインスタンスが侵害されて不正な仕組みが動いている場合は、侵害された原因を調査しなければ再発を防止できません。そのためまず保全します。インスタンスのAMIバックアップを再起動せず取得し、動かしたままSecurity Groupを変更して殆どの通信を拒否します。専門家に調査してもらうためにメモリや内部状態を可能な限りそのまま保持しておきます。

IAMタイプ

IAMタイプは漏洩したクレデンシャルがあればその無効化・削除を行い被害を最小限にすることが優先されます。もしクレデンシャルが悪用されていれば、他にも影響を受けるIAMやコインマイニングしているEC2、S3データの搾取など各種リソースに影響が広がっている可能性を考慮しDetectiveなどで影響範囲を特定します。影響範囲全体のログ調査・内部調査と対応が必要です。

S3タイプ

S3タイプは公開されるべきでないものが公開されていたら、非公開あるいは削除しつつだれがアクセスしたかをS3データアクセスログなどからたどります。S3データアクセスログは設定していない事が多いので重要な情報を扱うS3では事前に必ず有効化します。

抑止

調査した結果対応しなくていいイベントだった場合で、かつそれが頻繁に検知される場合にはイベントを抑止することが可能です。抑止した場合は当然イベントに気づけなくなるため、よく判断して抑止します。

抑止の設定はFindings Typeだけではなく、複合条件で設定可能です。Findings Typeと対象のリソースの組み合わせが比較的使いやすい抑制ルールです。以下のように詳細画面の+ボタンから検索条件を作成し、結果の抑止の登録を行うと、以降このルールに沿ったFindingsはイベント通知されません。